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ABSTRACT:  Key  to  the  future  interoperability  of  Simulations  with  Command,  Control,  Communications,  Computers 
and  Intelligence  (C4I)  systems  is  the  Defense  Information  Infrastructure  Common  Operating  Environment  (DII  COE) 
Architecture.  The  DII  COE  is  composed  of  configurable,  layered,  reusable  software  components  that  work  together 
with  specific  C4I  mission  software  to  perform  a  task.  All  future  DoD  C4I  systems  will  design  to  the  DII  COE. 
However,  because  Modeling  and  Simulation  (M&S)  has  not  been  involved  with  the  development  of  Dll  COE 
components  to  date,  simulation  capabilities  fall  short.  Recently,  a  Dll  COE  Technical  Working  Group  (TWG)  was  set 
up  to  address  M&S  Functionality.  This  paper  describes  the  development  of  an  initial  Technical  Requirements 
Specification  (TRS)  that  will  formalize  M&S  Requirements  to  the  Dll  COE  Community’. 

The  DII  COE  M&S  TRS  seeks  to  identify  requirements  for  functions,  features,  and  capabilities  of  the  DII  COE  that 
would  facilitate  the  interface  of  models  or  simulations.  Through  implementation  of  these  M&S  requirements,  developers 
of  DII  COE  infrastructure  software  will  be  able  to  provide  this  missing  M&S  functionality.  DII  COE  TWGs  typically 
have  a  Software  Requirements  Specification  (SRS)  that  guides  the  development  of  common  infrastructure  software.  The 
DII  COE  M&S  TRS  identifies  requirements  in  other  SRS  (such  as  the  Common  Operational  Picture  TWG,  the  Message 
Processing  TWG  and  the  Data  Access  TWG),  as  well  as  unique  M&S  requirements  that  do  not  belong  in  any  other 
TWG  SRS. 

The  initial  TRS  is  organized  according  to  an  established  C4I/M&S  Interoperability  Technical  Reference  Model  (TRM) 
developed  over  the  last  three  years  and  cited  in  the  SISO  C4I  Study  Group  Report.  The  TRS  allocates  requirements  into 
the  three  main  categories  of  the  TRM  -  1)  Management  Control;  2)  Persistent  Data;  and  3)  Non-Persistent  Data.  The 
paper  describes  how  the  TRS  is  being  developed  within  the  DII  COE  TWG  structure,  the  organization  of  the  TRS,  gives 
an  overview  of  the  requirements,  and  gives  examples  of  the  software  functionality >  in  the  DII  COE  that  is  expected  to  be 
developed  from  these  requirements. 


1.  Introduction 

This  paper  describes  how  M&S  requirements  are  being 
introduced  into  the  Dll  COE.  Although  being  defined  as 
general  requirements,  it  is  expected  that  they  will  be 
refined  as  requirements  for  specific  DII  COE  segments. 
The  intent  is  to  develop  a  standardized  set  of  M&S 
services  within  the  DII  COE.  These  M&S  services  may 
result  in  new  segments  (software)  within  the  Dll  COE, 
included  as  new  functionality,  or  added  as  new  interfaces 
to  existing  segments.  An  example  of  a  new  segment 


might  be  a  scenario  builder  segment  or  data  collection 
management  segment.  An  example  of  new  functionality 
is  the  work  done  to  allow  the  Dll  COE  Common  Message 
Processor  Segment  to  automatically  parse  and  format 
messages  for  M&S. 

The  purpose  of  this  paper  is  to  both  give  a  status  of  the 
Dll  COE  M&S  TWG  requirements  work  and  to  make  a 
case  for  and  request  involvement  from  the  SISO 
community. 
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1.1  Background 

At  the  end  of  1999,  the  DII  COE  Architectural  Oversight 
Group  (AOG)  convened  a  study  group  to  determine  if  an 
M&S  TWG  should  be  formed.  At  the  beginning  of  2000, 
the  recommendation  was  made  to  the  AOG  to  form  an 
M&S  TWG,  with  the  Defense  Modeling  and  Simulation 
Office  as  the  Chair. 

There  are  currently  no  standard  Simulation  Infrastructure 
Components  in  the  Dll  COE.  The  M&S  TWG  is  currently 
sponsoring  two  primary  tasks:  1)  segmenting  the  High 
Level  Architecture’s  (HLA)  Run  Time  Infrastructure 
(RTI),  and  developing  a  Requirements  Specification.  The 
larger  challenge  is  to  identify  which  functionality  is 
needed  to  facilitate  M&S  integration  and  interoperability 
with  the  DII  COE. 

All  Dll  COE  TWGs  are  required  to  produce  a 
requirements  document.  As  will  be  described  in  Section 
2.2.1,  this  is  usually  a  Software  Requirements 
Specification  (SRS),  but  could  also  be  a  more  general 
Technical  Requirements  Specification  (TRS).  This  paper 
describes  the  initial  requirements  document  (TRS)  that  is 
available  as  [4],  This  TRS  will  be  continually  refined  and 
presented  to  the  AOG  later  this  year. 

1.2  Scope 

The  scope  of  this  paper  covers  the  software  development 
within  the  Dll  COE.  We  do  not  address  the  data 
interoperability  aspect  identified  in  Tolk  [18].  We 
assume  a  general  knowledge  of  the  HLA  and  it’s  Interface 
Specification  and  the  Dll  COE  Architecture.  We  go  into 
detail  throughout  the  paper  where  we  feel  more  detail  is 
needed.  The  emphasis  is  to  present  the  initial  TRS 
requirements  and  request  involvement  to  refine  these. 

The  initial  TRS  is  organized  according  to  an  established 
C4I/M&S  Interoperability  Technical  Reference  Model 
(TRM)  developed  over  the  last  three  years  and  cited  in  the 
SISO  C4I  Study  Group  Report  [14].  This  has  been 
extensively  documented  in  the  SISO  literature  [1,  8,  9, 

13]. 

1.3  Roadmap  to  Paper 


architecture  from  a  software  developer’s  view  and  the 
functional  delineation  of  the  various  TWGs.  Section  3 
describes  how  the  Dll  COE  M&S  TWG  TRS  was 
constructed.  Section  4  presents  the  TRS  organization  and, 
most  importantly,  a  description  of  the  requirements. 
Section  5  offers  a  brief  conclusion. 


2.  The  DII  COE 

The  DII  COE  is  similar  to  the  HLA  in  that  it  is  an 
architecture  consisting  of  many  components  including  a 
software  infrastructure  and  a  collection  of  reusable 
software.  However,  where  the  HLA  has  one  primary 
software  component  -  the  RTI,  the  Dll  COE  has  many 
software  components.  This  is  because  the  HLA  is 
focused  on  interoperability  and  the  DII  COE  on 
development.  In  the  next  two  subsections,  we  describe 
the  DII  COE  Architecture  from  a  software  developer’s 
view  and  then  describe  the  TWG  structure.  For  more 
detailed  information  on  the  DII  COE,  refer  to  the  Dll 
COE  WWW  page  [3]  or  recent  SISO  papers  (such  as  [8]). 

2.1  DII-COE  Architecture 

The  Dll  COE  serves  as  a  foundation  for  building 
interoperable  systems  across  the  Department  of  Defense 
(DoD).  The  DII  COE  should  be  considered  a  “plug  and 
play”  open  architecture  designed  around  a  client/server 
model.  Functionality  is  easily  added  to  or  removed  from 
the  target  system  in  small  manageable  units,  called 
segments.  Segments  are  defined  in  terms  of  functions  that 
are  meaningful  to  users,  not  in  terms  of  internal  software 
structure  or  size.  Structuring  the  software  into  segments 
in  this  manner  is  a  powerful  concept  that  allows 
considerable  flexibility  in  configuring  the  system  to  meet 
specific  mission  needs  or  to  minimize  hardware 
requirements  for  an  operational  site.  Segmentation  is  the 
process  of  packaging  application  software  into  segments. 
This  process  includes  conforming  to  a  specified  directory 
structure,  creating  segmentation  descriptor  files,  and 
automating  the  installation  of  the  software  so  that  it  can 
be  installed  with  the  tools  provided  by  the  DII  COE 
runtime  environment.  Segmentation  is  necessary  but  not 
sufficient  to  achieve  the  required  level  of  Dll  COE 
runtime  compliance  mandated  in  the  Joint  Technical 
Architecture  (JTA)  [10].  Site  personnel  perform  field 
updates  by  replacing  affected  segments  through  the  use  of 
a  simple,  consistent,  graphically  oriented  user  interface. 


The  remainder  of  this  paper  is  organized  as  follows. 
Section  2  presents  a  description  of  the  Dll  COE 


2.2  DII-COE  Technical  Working  Groups 

The  DII-COE  Technical  Working  groups  (TWG)  were 
established  to  identify  or  review  and  consider  the 
requirements,  needs,  and  interests  of  a  number  of 
specific  areas  within  the  DII-COE.  Per  the  Dll  COE 
Architecture  Oversight  Charter  [3],  portions  of  the  DII 
COE  are  being  updated  using  requirements  generated 
by  approximately  20  joint  service  Technical  Working 
Groups  (TWGs).  Each  group  focuses  on  a  well-defined 
functional  area  (such  as  Kernel;  Mapping,  Charting  and 
Geodesy;  Alerts)  and  identifies  requirements  for 
hardware  and/or  software  components  that  will 
contribute  to  functional  capabilities  to  answer  these 
requirements.  Once  identified,  these  requirements  are 
documented,  published,  and  made  available  to  those 
who  seek  to  create  functional  components  to  provide 
the  capabilities.  More  information  about  the  specific 
TWGs  and  current  requirement  specifications  are 
available  from  the  TWG  DII-COE  website  [5],  A 
listing  of  the  TWGs  is  given  in  Table  1. 

A  recent  addition  to  the  TWGs  was  the  Modeling  and 
Simulation  Technical  Working  Group  (M&S  TWG).  It 
was  established  to  identify  potential  M&S  requirements 
for  incorporation  under  the  DII  COE.  Efforts  that  are 
focusing  on  the  integration  of  C4I  systems  with  modeling 
and  simulation  products  are  of  particular  importance  to 
the  group.  The  TWG  meets  every  3-6  months  to  review 
various  projects  in  the  C4I-Sim  community  and  to  help 
codify  requirements.  Recently,  a  DRAFT  version  of  the 
requirements  specification  has  been  developed,  and  made 
available  for  review  and  comment  [4],  This  document  will 
serve  to  guide  other  TWGs  and  developers  of  DII-COE 
segments  in  the  particular  requirements  of  those  who  wish 
to  interface  M&S  applications  with  DII-COE  segments.  It 
also  serves  to  guide  those  who  wish  to  develop  M&S 
applications  as  DII-COE  segments. 

2.2.1  M&S  TRS  Background 

When  this  task  was  originally  undertaken,  it  was 
determined  that  the  appropriate  form  of  output  for  the 
requirements  from  the  DII-COE  M&S  TWG  should  be  a 
Technical  Requirements  Specification  (TRS),  rather  then 
a  System  or  Software  Requirement  Specification  (SRS). 
This  distinction  was  made  that  a  TRS,  a  more  general 
classification,  specifies  requirements  that  can  be 
implemented  in  HW,  SW,  or  both.  Also,  it  identifies 
requirements  that  can  be  implemented  throughout  a 
variety  of  lower  level  systems.  The  precedent  for  this, 
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Table  1  -  DII  COE  TWGs 

•  Administration  Services  TWG 

•  Alerts  Services  TWG 

•  Common  Operational  Picture  TWG 

•  Communications  Services  TWG 

•  Configuration  Management  (CM)  TWG 

•  Data  Access  Services  TWG 

•  Distributed  Computing  &  Object  Management 
Services  TWG 

•  Human  Computer  Interface  Style  Guide  TWG 

•  Kernel  TWG 

•  Mapping,  Charting,  Geodesy,  and  Imagery  TWG 

•  Message  Processing  TWG 

•  Modeling  and  Simulation  TWG 

•  Multimedia/Collaborative  Services  TWG 

•  Network  Management  Services  TWG 

•  NT  Advisory  Group 

•  Office  Automation  TWG 

•  Real  Time  TWG 

•  Security  Services  TWG 

•  Toolkit  TWG 

•  Visualization  TWG 


within  the  DII-COE,  was  taken  from  the  Dll-COE 
Common  Operational  Picture  (COP)  TRS  [2].  This 
document  describes  the  requirements  imposed  upon  any 
and  all  providers  of  components  that  contribute  to  the 
COP,  which  represent  a  number  of  distinct  segments.  It 
also  implies  that  the  same  (or  similar)  requirements  may 
occur  within  a  number  of  requirement  specifications, 
rather  then  simply  appearing  in  a  single  one. 

Some  Requirements  within  the  M&S  TRS  are  general  in 
nature  and  subject  to  interpretation,  refinement,  and 
implementation  within  segments  submitted  for  acceptance 
within  the  DII-COE.  It  is  expected  that  other  TWGs,  and 
designers  of  DII-COE  segments  will  consider  the  M&S 
TWG’s  requirements  in  light  of  operational  requirements 
for  their  specific  segments.  It  is  expected  that  they  will 
make  modifications  and/or  additions  to  facilitate 
interfacing  Modeling  and  Simulation  components  to  their 
segments.  In  some  cases,  SRSs  may  include  M&S 
components  themselves,  and  would  find  adoption  of  these 
specifications  beneficial  not  only  as  guides  for  their 
simulation  components,  but  also  to  facilitate  their  use  by 
external  projects. 
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Figure  1  shows  the  relationship  of  the  M&S  TRS  and  the 
Dll  COE  SRSs.  Where  possible,  requirements  relevant  to 
individual  SRS’s  are  cited  in  the  M&S  TRS.  Where 
necessary,  new  requirements  will  be  developed  and  reside 
only  in  the  M&S  TRS.  The  following  sections  draw  upon 
the  Draft  M&S  TRS  and  describe  these  general 
requirements. 

3.  M&S  TRS  Genealogy 

The  M&S  TRS  starts  by  describing  the  modeling  and 
simulation  domain  for  the  TRS  reader.  It  describes 
various  types  of  M&S  applications,  as  well  as  some 
example  uses  for  modeling  and  simulation.  This  is  done 
not  as  an  attempt  at  an  exhaustive  overview  of  the 
domain,  but  rather  as  an  introduction  or  overview  for 
those  within  the  Dll-COE  domain  who  may  be  unfamiliar 
with  M&S  uses.  Numerous  examples  are  given  and  links 
are  made  to  documents  within  M&S  literature  for  those 
who  wish  to  pursue  further  reading  in  the  area. 

The  TRS  then  discusses  various  levels  of  relations 
established  between  the  DII-COE  and  M&S  applications. 
The  C4ISR/M&S  Interoperability  TRM  and  the  seven 
classes  of  simulation  services  in  the  HLA  Specification 
were  used  to  organize  the  requirements  in  Section  3.  The 
Management  and  Control  Services,  in  Section  3.1, 
correspond  to  the  “Exercise  Control”  category  of  the 
TRM  as  well  as  some  of  the  Service  Classes  in  the  HLA 
Specification.  Section  3.1  is  broken  down  into  5 
subsections:  M&S  Services,  Time  Management, 
Communications,  Distribution,  and  Management 


Authority.  M&S  Services  corresponds  to  the  Federation 
Management  Services  in  the  HLA  Specification.  Time 
Management  corresponds  to  the  same  Services  in  the 
HLA  Specification.  Communications  corresponds  to  the 
Data  Distribution  Services  in  the  HLA  Specification. 
Distribution  corresponds  to  the  Declaration  Management 
Services  in  the  HLA  Specification.  And  Management 
Authority  corresponds  to  the  Ownership  Management  in 
the  HLA  Specification 

Figure  2  illustrates  the  C4ISR/M&S  Interoperability 
Technical  Reference  Model  (TRM)  that  is  used  to 
describe  and  organize  virtual  connections  between  C4I 
system  components  and  M&S  components.  The  TRM  was 
originally  developed  by  Carr  &  Hieb  [1]  and  refined  by 
various  other  efforts  [8,  9,  13].  It  is  currently  being 
solidified  and  proposed  as  a  standard  SISO  product  [14]. 
Within  the  purposes  of  the  DII-COE  M&S  TRS  the  TRM 
was  used  to  organize  and  suggest  groups  of  requirements 
by  their  relationship  to  the  information  flows  between  (or 
those  wholly  contained  within)  potential  C41  system 
components  (segments)  and  M&S  components.  The  3 
groups  of  requirements  are  defined  below. 

4.  M&S  TRS  Requirements 

The  intent  of  the  DII-COE  Modeling  and  Simulation 
Requirements  is  to  identify  what  can  be  done  to  facilitate 
integration  of  M&S  applications.  Past  efforts  at 
integration  have  been  difficult  due  to  a  variety  of  factors, 
many  of  which  have  resulted  in  specific  requirements.  In 
other  cases,  M&S  integration  efforts  have  been  limited  by 


Figure  1  -  Relationship  between  M&S  TRS  and  other  DII  COE  SRSs 
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Figure  2:  C4ISR/M&S  Interoperability  Technical  Reference  Model 


limited  access  to  existing  segment  APIs. 

The  following  sections  discuss  the  requirements  placed  in 
each  referenced  section,  some  of  the  background  or 
rational  for  including  the  requirements,  and  the  intended 
impact  on  DII-COE  engineers  and  or  segment  developers. 
As  the  requirements  are  currently  in  DRAFT  form,  and 
being  considered  and  discussed  by  the  DII-COE  TWO, 
they  are  not  literally  reproduced  here.  However,  interested 
readers  are  strongly  encouraged  to  access  the  actual 
document  at  http://www.dmso.mil/index.php7pageM  8 1 
for  review,  and  provide  comments  or  input  to  TWO 
members. 

Interested  readers  should  note  that  there  is  a  correlation 
between  the  following  sub-sections  of  this  paper  and 
sections  of  the  TRS.  For  each  section  of  this  paper 
discussion  (e.g  4.1  Management  &  Control)  there  is  a 
similar  TRS  section  (e.g.  3.1  Management  &  Control). 
This  correlation  is  true  for  all  requirement  sections,  and 
was  matched  as  of  TRS  Draft  version  0.8 

As  mentioned  previously,  Figure  2  illustrates  the 
C4ISR/M&S  Interoperability  TRM.  It  is  used  to  describe 
and  organize  virtual  connections  between  C41  system 
components  and  M&S  components.  This  TRM  was  used 
to  suggest  the  overarching  classifications  for  requirements 
contained  within  the  TRS.  As  a  major  classification 
heading,  the  more  general  “Management  and  Control” 
was  used  instead  of  “Exercise  Control  Interactions”  for  2 


reasons.  First,  because  it  was  recognized  that  M&S 
applications  are  used  other  then  in  an  “Exercise”  or 
training  environment.  As  should  be  known  by  the  reader, 
they  may  also  be  used  for  analysis,  acquisition,  mission, 
and  test  &  evaluation. 

The  other  reason  was  recognition  that  “Control”  aspects 
of  the  1 sl  category  may  be  bi-directional.  In  addition  to  the 
original  capability  for  C41  systems  to  control  simulations, 
it  would  be  desirable  to  allow  for  the  capability  for 
simulations  to  control  or  “influence”  aspects  of  C4I 
system,  beyond  delivery  of  simulated  products.  These 
observations  are  being  fed  back  into  the  TRM  working 
group  for  consideration. 

The  other  2  classifications  of  requirements  are  more 
directly  drawn  from  the  TRM  and  reflect  requirements  for 
“Sharing  Persistent  Data”  and  “Sharing  Non-Persistent 
Data”  respectively. 

4.1  Management  &  Control 

These  requirements  represent  those  levied  on  DII-COE 
application  users  to  control  simulations  through  DII-COE 
services.  Examples  of  these  types  of  interactions  might  be 
the  ability  to  start,  pause,  or  reset  a  simulation.  Further, 
this  category  includes  requirements  that  may  be  imposed 
on  other  DII-COE  services  to  allow  control  by 
simulations.  Examples  might  be  the  ability  to  set/reset 
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system  time  or  other  system  settings,  deny  or  allow 
particular  capabilities/resources,  etc. 

It  should  be  noted  that  categories  for  some  classes  of 
requirements  within  the  TRS  draw  upon  the  High  Level 
Architecture  (HLA)  as  a  model.  It  was  felt  that  the 
original  HLA  specifications,  as  well  as  the  6  categories 
for  functions  within  the  RunTime  Infrastructure,  provide  a 
good  overall  structure.  Also  it  was  felt  that  following  the 
categorizations  for  Dll-COE  requirements  in  these 
sections  would  help  to  frame  their  relationship  to  potential 
areas  in  the  modeling  and  simulation  domain. 

4.1.1  M&S  Services 

This  section  defines  requirements  requested  by  the  M&S 
domain  of  the  DII-COE  system.  Included  in  this  are 
general  requirements  levied  upon  Mission  Applications, 
as  well  as  requirements  for  Initialization,  and  Control. 

An  example  of  the  types  of  problems  that  this 
requirements  section  addresses  includes  the  ability  to 
integrate  M&S  applications  seamlessly  within  the  native 
DII-COE  Mission  Applications.  Past  efforts  at  integration 
required  treatment  of  M&S  applications  as  separate 
entities  within  training  environments,  with  no  connection 
to  the  native  system.  Specific  concessions  for  individual 
projects  included  modifications  made  to  operational  menu 
items  to  allow  training  applications  to  be  loaded. 
However,  these  changes  were  made  to  non-operational 
C4I  systems  at  considerable  M&S  development  expense. 
Further,  it  had  to  be  replicated  for  each  version  of  the  C4I 
system  and  M&S  application.  It  is  proposed  that 
requirements  defined  in  this  section  could  embed  hooks 
within  the  native  system  to  facilitate  this  type  of 
integration  with  minimal  effort. 

Requirements  for  Initialization  seek  to  establish  that  there 
should  be  a  recoverable,  single  start  (or  initial)  state  for  a 
DII-COE  system,  and  the  facilities  should  be  available  for 
M&S  applications  to  trigger  a  return  to  this  state. 

Control  requirements  cover  general  issues  of  archive, 
retrieval,  and  playback  control.  This  section  was 
essentially  drawn  from  a  similar  section  of  the  COP  TRS. 

4.1.2  Time  Management 

Requirements  in  this  section  discuss  the  proposed 
relationship  between  system  time,  segment  operation,  and 
simulation  delivery  of  products  to  specific  segments.  It 
seeks  to  encourage  segments  to  rely  less  upon  the  system 
clock  as  part  of  their  processing,  which  in  the  past  has 
caused  problem  when  simulated  products  have  been 
available  a  greater  then  (or  less  then)  real  time  rates. 


It  also  seeks  to  establish  a  standard  suite  of  operational 
functions,  (e.g.  Start,  Stop,  Pause,  Continue)  for  internal 
simulations  that  would  match  potential  actions  available 
for  external  applications.  This  would  have  the  benefit  of 
creating  a  synergy  for  internal  and  external  simulations 
and  increase  the  potential  to  use  internal  simulations  and 
display  functions  for  rehearsal,  exercise,  and  after-action 
review  systems. 

4.1.3  Communications 

This  section  covers  the  general  area  of  accepting  external 
simulated  communications,  as  well  as  the  specific  area  of 
configuration  for  communications  resources.  It  proposes 
that  external  simulations  may  send  and  receive  messages 
with  the  system.  It  also  proposes  that  communications 
resources  and  database  management  plans  may  be  subject 
to  the  influence  of  simulations.  This  intent  of  these 
requirements  is  to  address  problems  encountered  during 
past  integration  efforts.  The  problems  occurred  when 
attempts  to  modify  system  network  files,  communications 
tables,  address  books,  and  other  communications  or 
database  update  resources  would  not  only  be  ineffective 
for  integration  purposes,  but  would  be  terminally 
destructive  to  the  system. 

This  section  also  refers  and  defines  general  requirements 
based  on  COP  TRS  requirements  establishing  network 
and  communications  hierarchy  based  on  roles. 

Finally,  it  proposes  expansion  to  current  means  of 
establishing  data  feeds  to:  limit  extraneous  network  traffic 
in  reduced  network  configurations,  facilitate  use  of 
embedded  simulations,  and  allow  introduction  of 
simulated  GPS  feeds. 

4.1.4  Distribution 

This  section  extends  Communications  requirements  to 
include  the  ability  to  consider  M&S  components  as  part 
of  distribution  plans.  It  also  proposes  the  ability  to  mask 
the  presence  of  a  simulation  through  the  use  of  NO-OP 
surrogates.  These  requirements  are  intended  to  ensure  that 
internal  specifications  of  external  systems  (e.g.  address 
lists,  mailing  lists,  network  tables)  consider  M&S 
surrogates  as  possibilities.  It  also  proposes  the  availability 
of  NO-OP  constructs  for  active  workstations  as  a 
distribution  reduction  method. 

4.1.5  Management  Authority 

This  section  speaks  directly  to  the  ability  to  consider 
M&S  components  as  potential  replacements  for  ANY 
system  within  the  C4I  service  hierarchy. 
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4.2  Persistent  Data  Services  Requirements 

As  defined  in  the  TRM,  Persistent  Data  refers  to  those 
databases,  resources,  and  mechanisms  that  are  relatively 
stable  and  unchanging  during  an  operational  activity. 
Examples  include  Unit  Data  (e.g.  TOE,  Symbology), 
Terrain  Specifications,  etc.  Specific  requirements  for 
individual  classes  of  information  are  not  identified.  Rather 
these  requirements  are  more  generic,  suggesting  a  specific 
instantiation  within  a  lower  level  SRS  for  each  underlying 
data  type  within  the  SRS  domain. 

For  each  data  type,  it  is  requested  that  the  system  support 
the  use  of  simulated  version  of  the  data  for  the  following 
functional  capabilities;  initialization,  load  &  display, 
processing,  and  retrieval  of  source  and  processed  results. 
Further  requirements  establish  the  need  to  differentiate 
between  simulation  and  native  data  sources,  and  the 
protective  capability  to  restrict,  control,  and  purge 
simulation  products. 

Although  it  is  recognized  there  are  system  level  methods 
through  which  this  data  is  maintained,  M&S  applications 
frequently  desire  automated  initialization  or  modification 
to  these  data  sources  without  human  intervention. 
Similarly,  DU  COE  Services  may  desire  controlled 
initialization  or  modification  to  data  “owned”  by  M&S 
applications.  Requirements  that  fall  in  this  category  are 
those  that  impact  DII  COE  segments  that  maintain  or 
include  persistent  data  sources. 


4  .  3Non- Persistent  Data  Services 
Requirements 

This  section  establishes  requirements  for  M&S  Services 
provided  to  support  the  integration  of  models  and 
simulations  with  Non-Persistent  Data  sources  within  the 
core  DII-COE,  and  supported  mission  applications.  Non- 
Persistent  Data  is  considered  data  that  may  be  set  during 
initial  configuration  of  the  system  but  is  subject  to 
repeated  modifications  throughout  the  Mission 
Applications  use.  It  also  applies  to  transient  data  that  does 
not  exist  prior  to  Mission  Application  use  but  develops 
over  time.  Examples  of  such  data  sources  are  Orders, 
Reports,  Imagery,  Track/Position  reports,  etc. 

As  with  Persistent  Data  requirements,  it  is  suggested  that 
these  are  generic  and  should  be  instantiated  for  each 
lower  level  source  with  the  individual  SRS.  They  are 
predicated  on  the  need  for  M&S  applications  to  access 
information  components  in  their  initial  form  (e.g. 
messages).  Also  that  any  products,  or  databases,  which 
result  from  processing  of  these  information  components 
be  available  for  interested  integration  efforts.  Examples  of 
the  use  of  these  items  include  stimulation  with  simulated 
versions  of  valid  sources  and  data  collection  for  after 
action  review. 

For  convenience,  the  requirements  within  this  section 
have  been  divided  into  2  distinct  sub-categories:  Orders, 
Messages,  and  Database  Updates  as  well  as  User 
Defined  Parameters. 

4.3.1  Orders,  Messages,  and  Database 
Updates 

These  requirements  apply  to  data  components  which  are 
normally  received  from  external  sources,  or  are  part  of 
processing  which  occurs  as  a  result  of  such  a  data 
component.  Examples  include  Strategic  or  Tactical 
messages  in  Service  formats  native  to  the  system  (e.g. 
USMTF,  OTFI-Gold,  VMF)  or  database  updates  received 
as  part  of  normal  system  operation  (e.g.  Track  Updates). 
It  also  applies  to  such  computer  system  service 
components  such  as  Global  Positioning  System  (GPS) 
feeds  and  TCP/IP  networking  service  tests  (e.g.  “ping”) 

Potential  benefits  derived  from  these  requirements  include 
the  ability  to  stimulate  the  system  with  simulation 
generated  equivalents,  data  collection  for  after  action 
review,  and  injection  of  simulation  surrogates  to  native 
message  processing  systems.  Specific  requirements 
within  this  section  discuss  simulation  product  acceptance, 
processing,  as  well  as  retrieval  of  source  and  processed 
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results.  Further  requirements  discuss  issues  involving  the 
discrimination  between  live  and  simulated  products  and 
potential  exclusion  of  simulated  products. 

4.3.2  User  Defined  Parameters 

These  requirements  apply  to  parameters,  settings,  and 
configuration  information  available  to  and  modified  by 
the  user  during  normal  operation.  This  information 
includes  both  “set  and  forget”  parameters,  which  may  be 
established  once  during  an  operation,  and  settings  which 
are  modified  repeatedly  during  system  use.  Actual 
parameters  are  numerous,  but  examples  include: 
Mail/Distribution  Lists,  Screen  Settings  &  Preferences, 
Alert  and  Filter  Settings,  or  Overlay  settings  and  groups. 

Similar  to  externally  produced  simulation  products 
referenced  in  4.3.1,  it  is  proposed  that  the  requirements 
identified  in  this  section  would  cause  user  modifications 
to  be  made  available  to,  and  potentially  influenced  by 
M&S  applications. 

5.  Conclusions 

In  this  paper,  we  describe  current  activities  to  establish  a 
set  of  requirements  for  M&S  within  the  DII  COE.  Our 
purpose  is  to  clearly  delineate  to  the  DII  COE 
development  community  those  common  services  that  are 
needed  to  “build  in”  interoperability  and  also  M&S 
functionality.  We  firmly  believe  that  once  these 
requirements  are  approved  and  put  into  the  DII  COE 
architecture,  they  will  have  a  synergistic  effect. 

The  FILA  provides  an  excellent  model  for  services 
necessary  for  simulations.  The  RT1  is  software  that 
implements  a  specified  interface  to  FILA  services.  It  still 
remains  to  segment  the  actual  services  themselves  (via  the 
RTI)  into  the  DII  COE.  Thus,  the  HLA  specification  can 
be  used  to  identify  necessary  APIs  in  the  DII  COE. 
Existing  APIs  can  be  mapped  to  the  required 
specifications  and  new  APIs  can  be  identified  for 
development. 

The  authors  recognize  the  enormous  investment  and 
legacy  of  the  D1I-COE.  We  suggest  that  the  M&S 
Community  continue  to  seek  opportunities  to  work  within 
the  Dll  COE  paradigm.  The  DII  COE  architecture 
provides  a  unique  opportunity  to  perform  integration  of 
simulation  infrastructure  and  functionality  into  the  C4ISR 
Domain. 
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